Built and tested locally.

Doesn't change anything, simply adds workaround for this issue leveraging already existing methods.

Also used windows clipboard for parity with template export to string, can change both together to IMGUI clipboard together.

Hi, thank you for your contribution. If imgui's clipboard functionality doesn't have any known issues then it would be great if you could replace all of the current winforms-based implementation of clipboard import/export with that so we no longer need to reference windows-specific code.

Having a look over at how Glamoure does this, OtterGui has this class to wrap the ImGui Clipboard functions,

using Dalamud.Bindings.ImGui;
using OtterGui.Text.HelperObjects;

namespace OtterGui.Text;

public static partial class ImUtf8
{
    /// <summary> Copy the given text to the clipboard. </summary>
    /// <param name="text"> The text as a UTF8 string. HAS to be null-terminated. </param>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void SetClipboardText(ReadOnlySpan<byte> text)
        => ImGui.SetClipboardText(text);

    /// <param name="text"> The given text as a UTF16 string. </param>
    /// <inheritdoc cref="SetClipboardText(ReadOnlySpan{byte})"/>
    /// <exception cref="ImUtf8FormatException" />
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void SetClipboardText(ref Utf8StringHandler<TextStringHandlerBuffer> text)
        => SetClipboardText(text.Span());

    /// <param name="text"> The given text as a formatted string. </param>
    /// <inheritdoc cref="SetClipboardText(ReadOnlySpan{char})"/>
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void SetClipboardText(ReadOnlySpan<char> text)
        => SetClipboardText(text.Span<TextStringHandlerBuffer>());


    /// <summary> Obtain the current text from the clipboard. </summary>
    /// <returns> An owned, null-terminated span of UTF8 text. An empty (still null-terminated) span on failure. </returns>
    public static TerminatedByteString GetClipboardTextUtf8()
    {
        var ptr = ImGui.GetClipboardTextU8();
        return ptr.Length is 0
            ? TerminatedByteString.Empty
            : ptr.CloneNullTerminated();
    }

    /// <inheritdoc cref="GetClipboardTextUtf8"/>
    /// <returns> A string of the current clipboard text. An empty string on failure. </returns>
    public static string GetClipboardText()
        => ImGui.GetClipboardText();
}

Would you like me to use these instead? Currently, template export to clipboard uses ImGui dirrectly.

Yea, copying the way glamourer/penumbra does things is always preferred. Just make sure you are not copying the code from OtterGui into C+, just update the submodule if it's too old and use those functions directly from there.

just checked, the submodule is up to date with the repo, so will just update all to use the wrapper class.

When changing template import/export and profile export to use wrapper ass i also found out that the functionality to copy / import bone groups is a thing (lmao) and that it uses ImGui clipboard.

Should I change this to also use the OtterGUI clipboard wrapper?

Besides that, a lot of debug functions use ImGUI directly, but I think those can just keep using it directly, altough it's up to you.

Should I change this to also use the OtterGUI clipboard wrapper?

Yea, let's do that.

Besides that, a lot of debug functions use ImGUI directly, but I think those can just keep using it directly, altough it's up to you.

You you feel like you can improve something and got some time for that - feel free to do that!

Should I change this to also use the OtterGUI clipboard wrapper?

That should be all done now.

Regarding the debug functions, the wrapper is pretty minimal, handling both text span directly or UTF8Stringhandler objects as the parameter, so I doubt there is much value swapping the debug copy to clipboard functions to use the wrapper instead.

Also, I did notice that the "You have unsaved changes in current template" menu doesnt is not big enough for all 4 buttons, i just adjusted the W scale of it to be fine. As it's based on Viewport Width, im assuming on ultrawide its fine, but on 16:9 it the "Keep editing" button was cut off, while as now, all buttons are visible fine even on 16:9

As the main goal of the PR is all done and tested fine, I'll mark this as ready for review.

I do wanna say that due to me being new to using Visual Studio, I kept the import statements as for some reason it's having trouble displaying to me if the imports are still in use, and I was getting some crashes when accessing some file selection stuff with the "using System.Windows.Forms" statement removed even though it compiles fine.

Also, I did notice that the "You have unsaved changes in current template" menu doesnt is not big enough for all 4 buttons, i just adjusted the W scale of it to be fine. As it's based on Viewport Width, im assuming on ultrawide its fine, but on 16:9 it the "Keep editing" button was cut off, while as now, all buttons are visible fine even on 16:9

I would advise against adjusting that without testing it on various resolutions because windows like this aren't being properly dynamically adjusted to the resolution right now and you might end up breaking it for a lot of people.

Anyway the code seems to be more or less fine so I'll merge it and adjust a bit.

If you'll be willing to test the window width change with multiple resolutions - feel free to make a new PR for it, for now I'll revert that change.

Thanks for your contribution!